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(57) ABSTRACT 

A system, method, and program for providing language 
translators with contextual information for the text to be 
translated. The translator is presented with a graphical user 
interface in the base language, and can then interactively 
translate each text label on the screen. Because the transla- 
tion is performed on the text in the proper context, the time 
and expense of Translation Verification Testing is reduced or 
eliminated. The contextual presentation of the text is accom- 
plished by creating a "facade" class which includes Java 
JComponents and adds additional attributes to each member 
component. The additional attributes include the Java 
resource bundle name and key for each J Component. 
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INTOOSPECTIVE EDITOR SYSTEM, 
PROGRAM, AND METHOD FOR SOFTWARE 
TRANSLATION USING A FACADE CLASS 



BACKGROUND OF THE INVENTION 

Cross Reference to Related Applications 

Ttiis application shares common text and figures with 
commonly assigned, copending application Scr. No. 09/034, 
754, "Introspective Editor System, Program, And Method 
For Software Translation", Ser. No. 09/362,616, "Introspec- 
tive Editor System. Program, and Method For Software 
Translation Using a Facade Class", Ser. No. 09/362,617, 
"System, Program, and Method For Performing Contextual 
Translations", and application Ser. No. 09/362,618, 
"System, Program, And Method For Software Translation 
Using a Wrapper Class", which are hereby incorporated by 
reference. 

1. Technical Field 

The present invention generally relates to tools for devel- 
oping software for international use and in particular to 
multi-language software development. Still more 
particularly, the present invention relates to an improved 
system and method for performing language translation in 
computer software. 

2. Description of the Related Art 
Software Internationalization 

As computers have become more prevalent, it has become 
desirable for software developers to be able to market their 
products to those people who do not speak the native 
language of the software developers. In particular, it is 
desirable that software developed in the English language be 
available to those persons, both in the United Slates and in 
the rest of the world, that do not speak English. Accordingly, 
many software applications that are developed in English are 
later translated for use by non-English speakers. 

The process of translating a software package into another 
(or more than one other) language is time-consuming and 
expensive. Each text message, menu, and button must be 
translated to allow the user to operate the program. The most 
direct way to do this is to search the entire program source 
code for every text string, i.e., every string of characters that 
would be displayed to the user, and translating each of these 
to the new language. 

This approach has several problems. One problem is that 
the use of this method means that the software must be 
specifically translated and compiled for each intended lan- 
guage. This, of course, is an expensive process in itself, and 
means that any change in the source code requires each 
language version of the code to be edited and recompiled. 

FIG. 2 shows an example of hardcoded labels in a Java 
application. In this Figure, window 200 shown with two 
graphical user interface (GUI) "buttons" 210 and 230. These 
buttons are created using a hard-coded Java "JButton" call; 
for example, code-line 220 calls JButton with the string 
argument "Ok", creating button 210 with text label "Ok". 
Similarly, code-line 240 calls JButton with the string argu- 
ment "Cancer, creating button 230 with text label "Cancer. 
To translate a software application which uses hard-coded 
strings as in FIG. 2, each line of the code must be parsed and 
each displayed string must be individually translated for 
each target language. 

One solution to this problem is the use of separate 
localization files, in which the text strings that are to be 
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displayed are stored separately firom the executable code 
itself. As the software is executed, the text for every given 
display screen is simply read from the localization files, in 
whichever language is stored in the file. In this manner, the 

5 text in the localization file can be translated without dis- 
turbing the executable, and the executable can be changed or 
replaced without disturbing the translated text (except, of 
course, that if the text to be displayed changes, the corre- 
sponding entries in the localization files must also be 

10 changed). The localization files may be in any number of 
formats, including compiled message catalogs, Java 
resource bundles, HTML files, and many others. 

The use of localization files provides an easy way to do 
multiple translations, but presents an additional problem in 

15 that the translation is performed on text isolated in a separate 
file, without any kind of context for the translator. Because 
this is the case, the translation wiU often contain errors 
which would not be present if the translator had been able to 
perform the translation according to the context in which the 
text appears. 

However the translation is handled, each screen of the 
program in operation must then be proofiread to ensure that 
the translated text is properly displayed and properly trans- 
lates the text in the context of the display. Therefore, it has 
become common practice to hire individuals with back- 
grounds in other languages to proofread each screen of the 
translated program to detect any display, grammar, or other 
translation errors. This second phase is called Translation 
Verification Testing (TVT). 
^° FIG. 3 shows a chart of a translation and testing cycle 
according to conventional methods. A typical Company A, 
located in Country A, builds the application intended for 
Country B (310). Next, Company A packages and ships the 
application to Company B, located in Country B (320). 
Company B will then execute the application to test for any 
translation or internationalization errors (330). Company B 
will then do TVT testing, note any translation errors, and 
make any necessary retranslations (340). Company B then 
ships the corrections back to company A, and the process 
repeats until no more errors are found. 

According to this conventional process, each time an error 
is corrected or a change made in translation in Country B, 
the product must be rebuilt and repackaged in Country A 
before it is retested. Because of this, the TVT process is 
necessarily an expensive and lime -consuming process. It 
would therefore be desirable to provide a means to provide 
additional information to the translator, and contextual infor- 
mation in particular, so that the initial translation is as 
accurate as possible. By doing so, the cost and time required 
for TVT testing can be reduced or eliminated. 

Java 

Java is two things: a programming language and a plat- 
form. In one aspect, Java is a high-level programming 

55 language, and is unusual in that each Java program is both 
compiled and interpreted, to make it accessible to many 
platforms. Java is also a software-only platform that runs on 
top of other, hardware-based platforms. The Java platform 
has two components; the Java Virtual Machine (Java VM), 

60 amd the Java Application Programming Interface (Java 
APO- 

The Java VM is the base for the Java platform and is 
ported onto various hardware-based platforms. The Java API 
is a large collection of ready-made software components that 
65 provide many useful capabilities, such as graphical user 
interface (GUI) widgets. The Java API is grouped into 
libraries (packages) of related components. 
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JavaBeans brings component technology to the Java plat- 
form. JavaBeans API supports reuseable, platform- 
independent components. Using JavaBeans-compliant 
application builder tools, components can be combined into 
applets, applications, or composite components. JavaBean 5 
components arc known as Beans. 

SUMMARY OF THE INVENTION 

It is therefore one object of the present invention to 
provide an improved tool for developing software for inter- 
national use. 

It is another object of the present invention to provide an 
improved tool for multi-language software development. 

It is yet another object of the present invention to provide 15 
an improved system and method for performing language 
translation in computer software. 

The above as well as additional objectives, features, and 
advantages of the present invention will become apparent in 
the following detailed written description. 20 

A more efiScient translation process is made possible by 
providing a system and method for providing language 
translators with contextual information for the text to be 
translated. The translator is presented with a graphical user 
interface in the base language, and can then interactively ^ 
translate each text label on the screen. Because the transla- 
tion is performed on the text in the proper context, the time 
and expense of Translation Verification Testing is reduced or 
eliminated. The ability to edit the text within the application 
is achieved by adding an editor function to the software 
application itself. Each text label in the application is stored 
in a localization file as a component of a "facade" class 
which includes Java JComponents and adds additional 
attributes to each member component. The additional 
attributes include the Java resource bundle name and key for 
each JCompooent. When the editor is activated, the trans- 
lator can edit the text directly, and the contextual informa- 
tion is used to store the translation for later use. 
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The novel features believed characteristic of the invention 
are set forth in the appended claims. The invention itself 
however, as well as a preferred mode of use, further objects 
and advantages thereof, will best be understood by reference 45 
to the following detailed description of an illustrative 
embodiment when read in conjunction with the accompa- 
nying drawings, wherein: 

FIG. 1 depicts a data processing system in which a system 
in accordance with a preferred embodiment of the present 50 
invention may be implemented; 

FIG. 2 is an example of a GUI display with hard-coded 
text; 

FIG. 3 depicts a block diagram of a translation and testing 
process according to conventional methods; 

FIG. 4 is a block diagram of a translation and testing 
process in accordance with a preferred embodiment of the 
invention; 

FIG. 5 depicts an example of a GUI display using Java 
resource files, in accordance with a preferred embodiment of 
the invention; 

FIG. 6 is a block diagram of an introspection tool for a \ 
software application in accordance with a preferred embodi- / 
ment of the invention; 65 
/ FIG. 7 depicts a block diagram of a Java wrapper class in \ 
/ accordance with a preferred embodiment of the invention; j 
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FIG. 8 is a more detailed diagram of a Java wrapper class 
in accordance with a preferred embodiment of the invention; 
and 

FIG. 9 depicts a block diagram of a Java facade class in 
accordance with a preferred embodiment of the invention. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENT 

With reference now to the figures, and in particular with 
reference to FIG. 1, a block diagram of a data processing 
system in which a preferred embodiment of the present 
invention may be implemented is depicted. Data processing 
system 100 may be, for example, one of the computers 
available from International Business Machines Corporation 
of Armonk, N.Y. Data processing system 100 includes 
processors 101 and 102, which in the exemplary embodi- 
ment are each connected to level two (L2) caches 103 and 
104, respectively, which are connected in turn to a system 
bus 106. 

Also connected to system bus 106 is system memory 108 
and Primary Host Bridge (PHB) 122. PHB 122 couples I/O 
bus 112 to system bus 106, relaying and/or transforming data 
transactions from one bus to the other. In the exemplary 
embodiment, data processing system 100 includes graphics 
adapter 118 connected to I/O bus 112, receiving user inter- 
face information for display 120. Peripheral devices such as 
nonvolatile storage 114, which may be a hard disk drive, and 
keyboard/pointing device 116, which may include a con- 
ventional mouse, a trackball, or the like, are connected via 
an Industry Standard Architecture (ISA) bridge 121 to I/O 
bus 112, PHB 122 is also connected to Pa slots 124 via I/O 
bus 112. 

The exemplary embodiment shown in FIG. 1 is provided 
solely for the purposes of explaining the invention and those 
skilled in the art will recognize that numerous variations are 
possible, both in form and function. For instance, data 
processing system 100 might also include a compact disk 
read-only memory (CD-ROM) or digital video disk (DVD) 
drive, a sound card and audio speakers, and numerous other 
optional components. All such variations are believed to be 
within the spirit and scope of the present invention. Data 
processing system 100 and the exemplary figures below are 
provided solely as examples for the purposes of explanation 
and are not intended to imply architectural limitations. In 
fact, this method and system can be easily adapted for use 
on any programmable computer system, or network of 
systems, on which software applications can be executed. 

A typical translation process for a software application is 
comprised of two phases. In the first phase, the human 
language text for the application's human text elements are 
captured in text files and delivered to translators for trans- 
lation. These translators have not seen the application and 
thus have no contextual information about the actual usage 
of the text being translated. Thus the translation process is, 
by design, error prone. To resolve these errors and to 
validate the translated text, the second phase, Translation 
Verification Testing, is performed. 

The preferred embodiment simplifies the translation pro- 
cess by allowing the developer to merge the two phases of 
the translation process. This is accomplished by providing 
the translator with direct contextual information about the 
item being translated. As a result, the costly and time- 
consuming TVT phase can be reduced or eliminated. 

According to the preferred embodiment, an introspective 
editor is provided which allows direct editing of the inter- 
face components by a translator, saving the results of the 
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translation in a text file, which, in the preferred embodiment, 
is a Java resource bundle. This provides the translator with 
necessary context to perform an accurate translation, and so 
the translation can be much more accurate. 

With reference now to FIG. 4, a block diagram of an 
improved translation and testing process according to the 
preferred embodiment. Company A, located in Country A, 
builds the application intended for Country B (410). Next, 
Company A packages and ships the application to Company 
B, located in Country B (420). Company B will then execute 
the application to test for any translation or international- 
ization errors (430), Company B will then do TVT testing, 
note any translation errors, and make any necessary retrans- 
lation (440). Unlike the case described in FIG. 3, above, 
because the present embodiments allow the translations to 
be performed in context and stored locally, Company B can 
immediately retest the translations (430), without shipping 
the product back to Country A to rebuild first. As a result, the 
translation and testing phase is much more efficient than 
according to conventional means. 

Of course, it is possible that the testing phase in Country 
B will reveal other errors, such as programming problems, 
which are not corrected in the translation problems. In this 
case, the application is shipped back to Company A to be 
corrected, as in conventional processes. 

In accordance with several embodiments described 
herein, the translator will actually execute the software 
application which he is translating, and the disclosed 
embodiments provide means for the translator to directly 
select text from the screen and edit it in real time. Because 
the translator is actually seeing the application as the end- 
user will, the translations will be much more accurate. 

In use, the introspective editor, according to the preferred 
embodiment, is presented as a "pop-up" editor window to 
accompany the text to be translated. For example, if the text 
to be translated is found on a "button" on a windows-based 
graphical user interface (GUI), then the localization file will 
store basic contextual information regarding the button 
along with the text itself [just the AEF]. When the text is to 
be translated, the contextual information is read, and a 
button, with the original text, is displayed on the screen. 
When the translator selects the button, an editor pop-up 
window is displayed, and the translator will enter the trans- 
lated text for that button. The editor will close, and the 
translated text will be stored in a localization file, which is 
either in a new file or by overwriting the original text in the 
original file. Thus, the complete translation has been per- 
formed in the context in which the button will appear in the 
final application. 

In the preferred embodiment, a "ctrl-alt-shift" key com- 
bination is used to signify that the displayed text is to be 
translated. When the GUI window is displayed, by pressing 
"ctrl-alt-shift" and "right-clicking," with a mouse or other 
pointing device, on a text label in the display, the translator 
indicates that the text label is to be translated. An editor 
window opens, and the translator can enter new text directly 
into the editor window. When the translator is finished, the 
new text is stored for future use. 

By directly editing the text elements in the software 
application's user interface, and by providing context to the 
translators, this method can eliminate the TVT phase of the 
translation process, thus reducing time and errors. 

The editor is referred to as an "introspective" editor 
because, in this embodiment, it utilizes the introspection 
properties of the Java programming langua ge to view and 
edit controls with "setText" and "get'lext" methods. While 



some aspects of Java®, JavaScript®, JavaBeans®, and other 
Java-related tools are described herein, other material is 
available from Sim Microsystems, and can be foimd (as of 
Uie filing date of this application) at http://java.sun,com. 
5 f Each Java Bean component has its own features, includ- 
j ing its properties^ethods^nfl events. These features can 
\ be cxamined by Mother Beans^ b y a process known as in tro- 
Vpeclion. Beans support introspection in two ways: 
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/2 By adhering to specific rules, known as Resign pattern^ 
when nami ng Bean feature s. The java.beansJntrospec- 
tor cTa^ examines Beans for these design patterns to 
discover B ean features . The Introspector class relies on 
the corej^Section^IJ and 
3 By explicSly provi3mg property, method, and event 
information with a related Bean Information class. A 
Bean information class implements the Beanlnfo inter- 
face. A Beanlnfo class explicitly lists those Bean fea- 
nires that are to be exposed to application builder tools. 
Properties arc a Bean's appearance and behavior charac- 
20 teristics that can be changed at design time. Builder tools 
introspect on a Bean to discover its properties, and expose 
those properties for manipulation. 

Beans expose properties so they can be customized at 
design time. Customization is supported in two ways: By 
25 using property editors, or by using more sophisticated Bean 
customizes. Beans use events to communicate with other 
Beans. A Bean that wants to receive events (a listener Bean) 
registers its interest with the Bean that fires the event (a 
source Bean). Builder tools can examine a Bean and deter- 
mine which events that Bean can fire (send) and which it can 
handle (receive). 

Persistence enables Beans to save and restore their state. 
Once you've changed a Beans properties, you can save the 
state of the Bean and restore that Bean at a later time, 
property changes intact. JavaBeans uses Java Object Seri- 
alization to support persistence. 

A Bean's methods are no different than Java methods, and 
can be called firom other Beans or a scripting environment. 

Although Beans are designed to be understood by builder 
tools, all key APIs, including support for events, properties, 
and persistence, have been designed to be easily read and 
understood by human programmers as well. 

The Introspector class provides a standard way for tools 
to leara about the properties, events, and methods supported 
by a target Java Bean. For each of those three kinds of 
information, the Introspector will separately analyze the 
bean's class and superclasses looking for either explicit or 
implicit information and use that information to build a 
Beanlnfo object that comprehensively describes the target 
bean. 

Introspective Editor for Translation 
This embodiment provides a means to use class field 
values to allow the translation of software text. Each text 
label in a software display is stored as a class object. 

In this embodiment, the actual text to be displayed on, for 
example, a GUI button, is not hard-coded but is stored in a 
Java ResourceBundle localization file. With reference now 
to FIG. 5, and example of button labels being displayed 
using Java resource bundles is shown. In this Figure, win- 
dow 500 is shown with GUI buttons 510 and 530. Note that 
this window corresponds to window 200 of FIG. 2. Here, 
however, button 510 is created using a Java JButton call 520 
which refers to a ResourceBundle. 

In this example, the command "JButton(res.getString 
("OK")) 540 creates a GUI button, and labels it by doing a 
resource file lookup for the text that should correspond to an 
"OK" button. Java resource files are depicted collectively as 
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550, and an English language reference file is shown as 560. 
In file 560, entry 580 indicates that the text that corresponds 
to an "OK" button is "Ok". Therefore, command 520 creates 
a GUI button with the text "Ok". Note that in this example, 
for the sake of clarity, button names are shown in upper case, 
and button text labels are shown in mixed case. 

Similarly, the command "JButton(res.getString 
("CANCEL^) 540 creates a GUI button, and labels it by 
doing a resource file lookup for the text that should corre- 
spond to an "CANCEL" button. In file 560, entry 570 
indicates that the text that corresponds to an "CANCEL" 
button is "Cancel". Therefore, command 520 creates a GUI 
button 530 with the text "Cancel". Of course, the actual 
corresponding text in the resource file 560 can be anything; 
the entry 570 could read {"CANCEL", *'Stop"}, which 
would cause a button labeled "Stop" to be created every time 
command 540 was executed. Of course, this approach is not 
limited to GUI buttons, but may be used to look up any 
displayable text from the localization resource files. 

Since the resource files store the text to be displayed as 
Java objects, the introspective properties of the Java envi- 
ronment can be used to allow the translators to directly edit 
the application text using a pop-up editor. 

When the pop-up editor is activated, a getXext call is made 
to the target object, which returns the present text to the 
editor. This text is displayed to the translator, who then may 
edit it. After the translation/edit is complete, the new text is 
stored in the object using a setText call. 

Finally, the object, with the new text, is stored back into 
a Java Resource Bundle file. Thereafter, the software appli- 
cation can be executed using the modified objects, which 
will then show the translated text on the display. 

With reference now to FIG. 6, it should be noted that, in 
this embodiment, the introspective editor 610 is a separate 
software program than the application 650 that is being 
translated. The editor 610 contains the code for the Intro- 
spection Application Programming Interface (API) 620, the 
Editor GUI 630, and the File I/O system 640. The target 
application 650 stores the UI Objects 660, which contain the 
text strings to be translated, in Java resource files. 

The translator is, in this embodiment, simultaneously 
running the target application 650 and the introspective 
editor 610. When the pop-up editor is used, the introspective 
editor is retrieving and storing the objects fi"om the target 
application 650. 

Jav a Wrapper API 

Another implementation accomplishes the same 
contextual-translation results described above, but uses 
"wrapper** classes of Java Ul classes . J ava wrapper classc s> 
a llow m e p rogrammer to ^^ap" a Java component in to a 
n ew component, ^ which has all the attributes oi:' the ongin al 
c omponent plus one or more new or expanded attributes. 



"Store," but the other dialogs are to remain as "Save", the 
translator must know which resource file is actually used to 
display that label. Translators usually have access to the 
resource files but not to the program source, where the 
5 association of the GUI component and resource files is 
provided. The translator is forced to guess at which resource 
file is being used, which is a very inefficient, time consuming 
and error prone step. 
This embodiment provides a means to let the translator 
JO know which resource file and which key is used for the 
particular GUI label. To accomplish this, resource file name 
and key name must be added to the instance of GUI 
component as well as the label itself, using a Java wrapper 
class. Once this information is stored in the GUI 
55 components, the tool can display the resource name and key 
to the translator to be edited, or tool can even edit the 
resource file for the translator using the editor interface 
provided by the tool. 

The wrapper extends the Java class in two ways. One is 
20 to add two string attributes to store resource file name and 
key, and the other is to provide the constructors and methods 
to set/get those attributes. The constr uctors and methods o f 
wr appers are very similar to inose ol the parent classes. 
''setlext/getlext" is used to set and get the label of the text 
25 based component, which is always a text entry. Even if the 
program writes set1bxt(getKey( ...))> ^^^el is just 
resolved text, and does not contain resource file name and 

key. 

Thi s embodiment, using'lava wrapper cla^ il, has two 
30 advantages over tne embodiment described above, which 
relies only on the getText/setText method: 

1 The wrapper can store resource file name and key, 

whereas setText only stores the label. 
1 The wrapper's constructors sets resource file name and ^ 
35 key as well as the label. Without wrappers, developer is J 
required to call another method to set them whenever I 
he instantiates the GUI component with label, and this / 
step is frequently overlooked in development. / 
As shown in FIG. 7, this embodiment extends the Java 
40 Foundation Qass's text components, such as JButton 710, 
Jlabel 720, JCheckBox 730, and JMenu 740, to produce 
corresponding components TButton 712, TLabel 722, 
JCheckBox 732, and JMenu 742; of course, other JFC 
components can be similarly expanded. The new compo- 
45 nents add a get/set method for the resource bundle name 
(res) and key, for each component. 

With reference now to FIG. 8, a more detailed diagram of 
the component expansion for the "JButton" class is shown. 
In this Figure, JButton class 810 is extended, usin g a Java 
50 wrap per API, to a TButton class 820. The TButton class has 
the same "label" attribute 830 as the original JButton class, 
but adds attributes for the resource bimdle name (res) 840 
and the key 850. These allow the translator to direcUy bring 
up and edit the label attribute of each TButton, according to 
55 its key. 

Using this approach, the translator can bring up a popup 
menu on those components and directly edit/translate the 
label at run time. The changes to the labels are saved in a log 
file, according to the class and key, and also immediately 



This embodiment extends Java Swing components such 
as JButton to store a resource bundle name attribute and a 
key name attribute in the instance objects. The extended 
components implement constructors with these attributes 
and get/set methods. Those attributes can be displayed in a 
• popup dialog on those components and users can edit the 

/ label at ru n tim e. The dianges made i n the popup dialog is , „ ^, ^ 

I di rectly ^eflectc^ t o the application Ul component and s^^ cd 60 changed on the GUI display. Thereafter, when the software 

application encounters this class and key, the edited/ 
translated text is displayed. 

It should be noted that this embodiment, unlike the ^ 
introspection tool above, uses wrapper classes that are a part 
65 of the software application being translated. If the software 
application to be translated does not support the extended 
wrapper classes, this approach will not be effective. 



V in a log ^le . 

In a large application, the same text (such as "Save") 
might be defined in several resource files, and different 
dialogs could be using different resource files for the same 
label. 

If a translator found that a label "Save," for example, must 
be replaced in a given dialog with another word such as 
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Facade 

The preferred embodiment provides for attaching the 
per-component translation information to a JComponent by 
creating a "facade** class. In this embodiment, the access 
methods and editor user interface logic are centralized into 
a single "facade** class instead of having those in each 
wrapper classes. 

The application sets the resource bundle name and key 
[name of the Java UI component through this facade class. 
'Those attributes can be displayed in a popup dialog on those 
components and users can edit the label at run time. The 
changes made in the popup dialog is directly reflected to the 
application UI component and saved in a log file. 

This method solves the same problem as the wrappering 
approach above. The advantages of this approach over 
wrappering are: 

(1) Subclassing in the wrappering approach has a main- 
tenance overhead (new and updated JComponents 
require changes to the set of derived components), 

(2) Wrappering incurs a development overhead, in that 
designers are required to choose only from the set of 
available subclasses, or to implement their own, 

(3) Wrappering also incurs a runtime overhead, since the 
editor attribute must be built into each component), and 

(4) The setName( ) used in the wrappering embodiment 
involves combining all translation attributes into the 
component's "name" attribute, whereas the properties- 
based approach provides direct access to each transla- 
tion attribute, is more readily expandable (e.g. for 
tooltip text translation attributes), and leaves the com- 
ponent's "name" attribute available for other uses. 

This embodiment provides the class "NLSUtility," which 
works as a facade to JFC text components (JButlon, JLabel, 
JCheckBox, JRadioButton) and implements a get/set 
method for the resource bundle name and key. Those 
attributes are stored in a clientProperty hash table with 
access key. The user can bring up a popup menu on those 
components and edit the label at run time. The changes to the 
labels are saved in a log file. 

FIG. 9 shows a block diagram according to this facade 
class embodiment. Here, facade class 900 acts as a front end 
to the JFC text components 910, 920, 930 940 (and others, 
not shown), and associates vwth each of these a cUent 
property attribute. The facade class can then be used to 
directly read and edit the property attributes of the under- 
lying JFC foundation classes, by using putClientProperty( ) 
950 and getClientProperty( ) 960. By using the facade class, 
the same results as the wrappering embodiment, above, are 
achieved, but the overhead of the editor function is built into 
the facade class, instead of into each individual component. 

It is important to note that while the present invention has 
been described in the context of a fully functional data 
processing system and/or network, those skilled in the art 
will appreciate that the mechanism of the present invention 
is capable of being distributed in the form of a computer 
usable medium of instructions in a variety of forms, and that 
the present invention applies equally regardless of the par- 
ticular type of signal bearing medium used to actually carry 
out the distribution. Examples of computer usable mediums 
include: nonvolatile, hard-coded type mediums such as read 
only memories (ROMs) or erasable, electrically program- 
mable read only memories (EEPROMs), recordable type 
mediums such as floppy disks, hard disk drives and 
CD-ROMs, and transmission type mediums such as digital 
and analog communication hnks. 

While the invention has been particularly shown and 
described with reference to several preferred embodiments, 
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it will be understood by those skiUed in the art that various 
changes in form and detail may be made therein without 
departing from the spirit and scope of the invention. 
Furthermore, it will be understood that while specific data 
5 structures, fuoaions, and languages have been discussed, 
the disclosed techniques may be readily adapted to other 
programming environments without departing from the 
scope of the invention. 
What is claimed is: 
10 1. A method for editing textual data for a software 
program, comprising: 

displaying a first textual data by making a caU to a 
software object that includes source data related to the 
first textual data, the software object being a member of 
15 a class of Java objects, the class inclucling members 
which are Java component objects with additional 
source data attributes wherein the source data includes 
contextual data related to the first textual data; 
examining, in response to a user input, the software object 
20 to identify the source data; 

receiving a second textual data, corresponding to the first 

textual data, from a user input; 
storing the second textual data in a machine-readable 

form according to the source data; and 
displaying the second textual data in place of the first 
textual data on a computer display. 

2, The method of claim 1, wherein the machine-readable 
form is a localization file on a computer storage medium. 

3, The method of claim 1, wherein the second textual data 
is a translation of the first textual data. 

4, The method of claim 1, wherein the software object is 
a wrapper-class Java component. 

5, The method of claim 1, wherein the source data 
includes a reference to a Java resource bundle. 

6, The method of claim 1, wherein the source data 
includes a key associated with the first textual data. 

7, The method of claim 1, wherein the tiser input in the 
examining step is a mouse click. 

8, A computer system having at least a processor, acces- 
.sible memory, and an acces.sible display, the computer 
system comprising: 

means for displaying a first textual data by making a call 
to a software object that includes source data related to 
the first textual data, the software object being a mem- 
ber of a class of Java objects, the cla.ss including 
members which are Java component objects with addi- 
tional source data attributes wherein the source data 
includes contextual data related to the first textual data; 
5Q means for examining, in response to a user input, the 
software object to identify the source data; 

means for receiving a second textual data, corresponding 
to the first textual data, from a user input; 

means for storing the second textual data in a machine- 
55 readable form according to the source data; and 

means for displaying the second textual data in place of 
the first textual data on a computer display. 

9, The system of claim 8, wherein the machine-readable 
form is a localization file on a computer storage medium. 

dO 10. The system of claim 8, wherein the second textual data 
is a translation of the first textual data. 

11. The system of claim 8, wherein the software object is 
a wrapper-class Java component. 

12. The system of claim 8, wherein the source data 
65 includes a reference to a Java resource bundle. 

13. The system of claim 8, wherein the source data 
includes a key associated with the first textual data. 
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14. The system of claim 8, wherein the user input in the 
examining step is a mouse click. 

15. A computer program product having computer read- 
able program code on a computer usable medium, compris- 
ing: s 

instructions for displaying a first textual data by making 
a caU to a software object that includes source data 
related to the first textual data, the software object 
being a member of a class of Java objects, the class 
including members which are Java component objects 
with additional source data attributes wherein the 
source data includes contextual data related to the first 
textual data; 

instructions for examining, in response to a user input, the 
software object to identify the source data; 

instructions for receiving a second textual data, corre- 
sponding to the first textual data, from a user input; 

instructions for storing the second textual data in a 
machine-readable form according to the source data; 
and 
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instructions for displaying the second textual data in place 
of the first textual data on a computer display. 

16. The computer program product of claim 15, wherein 
the machine-readable form is a localization file on a com- 
puter storage medium. 

17. The computer program product of claim 15, wherein 
the second textual data is a translation of the first textual 
data. 

18. The computer program product of claim 15, wherein 
the software object is a wrapper-class Java component. 

19. The computer program product of claim 15, wherein 
the source data includes a reference to a Java resource 
bundle. 

20. The computer program product of claim 15, wherein 
the source data includes a key associated with the first 
textual data. 

21. The computer program product of claim 15, wherein 
the user input in the examining step is a mouse click. 
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